ソフトウェアアーキテクチャの基礎輪読会 2章
日付：11/2
調査者：kiri.icon
2章
アーキテクチャ思考とは
物事をアーキテクトとして見ること
アーキテクチャ的な観点から物事を見ること
アーキテクトらしく考えるとは、主に4つの側面がある
側面1
アーキテクチャと設計の違いを理解し、アーキテクチャを機能させるために、開発チームとどう協働するかわかる
側面2
ある程度に技術的な深さを維持しながらも、他の人には見えないソリューションや可能性を見いだせるような広範な技術知識を持つこと
側面3
様々なソリューションと技術の間にあるトレードオフを理解し、分析し、調整できること。
側面4
ビジネスドライバー(*1)の重要性を理解し、それがどのようにアーキテクチャの関心事に反映されるかを理解していること
*1: ビジネスを伸ばすために乗り越えなければならない要素のこと。
本章では、アーキテクトらしく考え、アーキテクチャの観点で物事を見るための、これらの4つの側面について探る。
2.1 アーキテクチャと設計
アーキテクトらしく考えるとは、アーキテクチャと設計の違いを理解し、この2つがどう密に結びついてビジネスや技術の問題に対するソリューションを形成するかを見極めること
従来の責務モデルの問題点
アーキテクトと開発チームを隔てている仮想的・物理的な壁を越える矢印が一方向なため、アーキテクト側の決定は開発チームにはうまく伝わらず、開発チームの決定はアーキテクトへとほとんど戻されない。
今日の責務モデルの特徴
アーキテクトと開発チームが実質1つのチームとなっている。
このモデルは、アーキテクチャと開発の間の強力な双方向コミュニケーションを促進するだけでなく、アーキテクトがチーム内の開発者にメンタリングやコーチングを行う機会も提供する。
今日のシステムアーキテクチャは、プロジェクトのイテレーションやフェーズと共に変化し、進化していく。
この2つはどちらもソフトウェアプロジェクトを構成するものであり、ソフトウェアプロジェクトの成功には両者が常に同期されていなければならないのだ。
2.2 技術的な幅
開発者とアーキテクトでは、求められる技術的な詳細の範囲が異なる
開発者
良い仕事をするためにかなりの技術的な深さを持たなくてはならない
ソフトウェアアーキテクト
アーキテクチャ視点で物事を見るために、かなりの技術的な幅が求められる。
個人の中にある知識は3つの領域に分けられる
3つの領域
1. わかっていること
ex. JavaプログラマーがJavaを理解している
2. わかっていないとわかっていること
ex. プログラミング言語Clojureは、名前は聞いたことがあり、Lisp由来のプログラミング言語であることは知っているものの、Clojureでプログラミングはできない。
3. わかっていないとわかっていないこと
取り組んでいる問題を解決するために最適でありながら、技術者がその存在を知らないような、技術、ツール、フレームワーク、言語が含まれる。
わかっていることは維持なければならないものでもある
Ruby on Railsの専門家になったとしても、1、2年Ruby on Railsから離れていたら、その専門知識は失われてしまう。
この領域の大きさが、最終的にその人の「技術的な深さ」になる
アーキテクトとしての価値
技術を幅広く理解し、それを使って具体的な問題を解決すること
アーキテクトであれば、ある問題に対して5つのソリューションがあるとわかっている方が、そのうちの1つの専門家であることよりも有益
「わかっていないとわかっていること」までが「技術的な幅」になる
2.3 トレードオフを分析する
アーキテクチャはすべてがトレードオフ
2.4 ビジネスドライバーを理解する
アーキテクトらしく考えるとは、システムの成功に必要なビジネスドライバーを理解し、それらの要件をアーキテクチャ特性（スケーラビリティ、パフォーマンス、可用性など）へと変換すること
それには、事業ドメインの知識をある程度持ち、主要なビジネスステークホルダーと健全で協力的な関係を築かなくてはならない。
2.5 アーキテクティングとコーディングのバランスを取る
すべてのアーキテクトがコードを書き、一定のレベルの技術的な深さを維持できるべき
ボトルネックの罠を避けるべき
アーキテクトがプロジェクトのクリティカルパスにあるコード（通常はフレームワークの基礎となるコード）の所有権を握り、チームのボトルネックになってしまうこと
ボトルネックの罠を回避するには
クリティカルパスやフレームワークのコードは開発チームの他のメンバーに委ねてしまい、1～3回のイテレーションで実現できそうな機能（サービスや画面）の開発に集中する。
アーキテクトが現場感を持ち続けるには
4つの基本的な方法がある
1. 概念検証を行う
プロダクションレベルの品質のサンプルを作り比較する
アーキテクチャのリファレンス実装が他の人にとってのサンプル実装になってしまうことがよくある
2. 技術的負債やアーキテクチャに関するストーリーを引き受ける
開発チームが重要で機能的なユーザーストーリーに取り組めるよう
3. 開発チームの日常業務を自動化する
ex. lint
4. まめにコードレビューする
アーキテクチャへの準拠を確認し、チーム内でメンタリングやコーチングの機会を得られる
応用
コードが出てこなかったのでなし
質疑応答